[XRegistry] Allow clients to use explicit registry roots - #4130

Add an explicit captured-call count assertion before the test indexes the first call. This keeps regressions failing with a meaningful NUnit assertion instead of an ArgumentOutOfRangeException.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

Pins the combined WoT Connectivity 1.1 NodeSet2 and its NodeId companion file
into the project and generates the model from them.

The combined NodeSet contains the complete published OPC 10100-1 v1.02 model
alongside the additive registry nodes in a single namespace, emitted under the
same prefix, name and model URI the standalone 1.02 model used. Every existing
1.02 generated constant, NodeState and proxy therefore keeps its exact NodeId,
so the model is additive rather than a replacement.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

Introduces the protocol-agnostic half of the WoT binding runtime: the binder,
planner, executor and channel factory contracts, the payload codec and
credential provider seams, the binding plan model, and the polling subscription
that drives forms without native observation.

Eight protocol planners are included - HTTP, CoAP, MQTT, Modbus TCP, BACnet,
PROFINET, LoRaWAN and OPC UA. A planner validates a form and produces a binding
plan; it performs no transport I/O, so this layer can be reviewed and tested
without any network stack. The concrete executors follow separately.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

…ient

…-15-client

Adds the client-side surface for the WoT Connectivity registry: browsing and reading registry groups, resources and versions, uploading documents through FileTransfer, and invoking the registry methods.

WotRegistryClient derives from the shared XRegistryClient so the generic registry traversal is not reimplemented here, and it takes an explicit registry root so a server that hosts the registry somewhere other than the well-known location can still be used.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

Reverts the temporary client-only compile exclusions so the WotCon test project keeps the existing server, provider and hosting tests from the base branch.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

The combined WoT Connectivity model generates DataTypeIds and the other identifier classes into the Opc.Ua.WotCon namespace, so an unqualified DataTypeIds in a file that imports that namespace now resolves to the generated class rather than to the standard one and the core identifiers stop resolving.

Qualifies the affected references in the WoT Connectivity server so it keeps building against the new model. No behaviour changes.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

…into marcschier/wot-15-client

…registry

The combined WoT Connectivity model includes the deprecated 1.02 asset surface and the additive registry nodes that reference xRegistry base types. Register the xRegistry namespace before creating the combined table, then retain only the legacy node slice for WotConnectivityNodeManager.

This keeps the existing asset-management NodeManager from claiming registry nodes or failing when xRegistry NodeIds are resolved. No behavior change outside the model partitioning needed by the combined NodeSet.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

…into marcschier/wot-15-client

Adds a stable, injectable registry for Thing Description and Thing Model documents, with in-memory and file-backed stores behind one interface.

The file-backed store commits atomically: content-addressed blobs are verified and skipped rather than rewritten, blob writes are staged under a temporary name and published in a single indivisible step through the file-system atomic-replace capability, and a commit that is interrupted leaves either the previous state or the new one, never a partially written blob that the manifest already references. Recovery artefacts left by an interrupted commit are detected and rolled back on load.

Documents are versioned with epochs and desired/active state, labels and bounds are persisted, and blob storage is delegated to the shared xRegistry resource store contract rather than reimplemented.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

The fluent builder generator emits calls to INodeManagerBuilder.VariableFromDataTypeId
and to a NodeManagerBuilder constructor overload that carries the data-type lookup, but
the runtime side of that API was missing, so every generated node manager failed to
compile with CS1729 and CS1061.

Adds the VariableFromDataTypeId resolution to the builder interface and implementation,
along with NodeStateLookupExtensions.FindByDataType, which is the lookup the builder
delegates to and has no other consumer.

Resolution reports BadNodeIdInvalid for a null data type, BadNodeIdUnknown when nothing
matches, BadBrowseNameDuplicated when the match is ambiguous, and BadTypeMismatch when
the resolved node is not a variable. An optional browse name disambiguates a data type
that is carried by more than one variable.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

The fluent builder generator emits calls to INodeManagerBuilder.VariableFromDataTypeId
and to a NodeManagerBuilder constructor overload that carries the data-type lookup, but
the runtime side of that API was missing, so every generated node manager failed to
compile with CS1729 and CS1061.

Adds the VariableFromDataTypeId resolution to the builder interface and implementation,
along with NodeStateLookupExtensions.FindByDataType, which is the lookup the builder
delegates to and has no other consumer.

Resolution reports BadNodeIdInvalid for a null data type, BadNodeIdUnknown when nothing
matches, BadBrowseNameDuplicated when the match is ambiguous, and BadTypeMismatch when
the resolved node is not a variable. An optional browse name disambiguates a data type
that is carried by more than one variable.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

The fluent builder generator emits calls to INodeManagerBuilder.VariableFromDataTypeId
and to a NodeManagerBuilder constructor overload that carries the data-type lookup, but
the runtime side of that API was missing, so every generated node manager failed to
compile with CS1729 and CS1061.

Adds the VariableFromDataTypeId resolution to the builder interface and implementation,
along with NodeStateLookupExtensions.FindByDataType, which is the lookup the builder
delegates to and has no other consumer.

Resolution reports BadNodeIdInvalid for a null data type, BadNodeIdUnknown when nothing
matches, BadBrowseNameDuplicated when the match is ambiguous, and BadTypeMismatch when
the resolved node is not a variable. An optional browse name disambiguates a data type
that is carried by more than one variable.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

The fluent builder generator emits calls to INodeManagerBuilder.VariableFromDataTypeId
and to a NodeManagerBuilder constructor overload that carries the data-type lookup, but
the runtime side of that API was missing, so every generated node manager failed to
compile with CS1729 and CS1061.

Adds the VariableFromDataTypeId resolution to the builder interface and implementation,
along with NodeStateLookupExtensions.FindByDataType, which is the lookup the builder
delegates to and has no other consumer.

Resolution reports BadNodeIdInvalid for a null data type, BadNodeIdUnknown when nothing
matches, BadBrowseNameDuplicated when the match is ambiguous, and BadTypeMismatch when
the resolved node is not a variable. An optional browse name disambiguates a data type
that is carried by more than one variable.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

The fluent builder generator emits calls to INodeManagerBuilder.VariableFromDataTypeId
and to a NodeManagerBuilder constructor overload that carries the data-type lookup, but
the runtime side of that API was missing, so every generated node manager failed to
compile with CS1729 and CS1061.

Adds the VariableFromDataTypeId resolution to the builder interface and implementation,
along with NodeStateLookupExtensions.FindByDataType, which is the lookup the builder
delegates to and has no other consumer.

Resolution reports BadNodeIdInvalid for a null data type, BadNodeIdUnknown when nothing
matches, BadBrowseNameDuplicated when the match is ambiguous, and BadTypeMismatch when
the resolved node is not a variable. An optional browse name disambiguates a data type
that is carried by more than one variable.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

DiNodeManager constructed NodeManagerBuilder without the data-type resolver, so
VariableFromDataTypeId reported BadNodeIdUnknown ("no predefined variable has DataType")
for every DI node manager - a misleading error, since the lookup had simply never
been supplied rather than the variable being absent.

Delegates to NodeStateLookupExtensions.FindByDataType rather than hand-rolling the
scan a fourth time in this file.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

DiNodeManager constructed NodeManagerBuilder without the data-type resolver, so
VariableFromDataTypeId reported BadNodeIdUnknown ("no predefined variable has DataType")
for every DI node manager - a misleading error, since the lookup had simply never
been supplied rather than the variable being absent.

Delegates to NodeStateLookupExtensions.FindByDataType rather than hand-rolling the
scan a fourth time in this file.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

DiNodeManager constructed NodeManagerBuilder without the data-type resolver, so
VariableFromDataTypeId reported BadNodeIdUnknown ("no predefined variable has DataType")
for every DI node manager - a misleading error, since the lookup had simply never
been supplied rather than the variable being absent.

Delegates to NodeStateLookupExtensions.FindByDataType rather than hand-rolling the
scan a fourth time in this file.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

DiNodeManager constructed NodeManagerBuilder without the data-type resolver, so
VariableFromDataTypeId reported BadNodeIdUnknown ("no predefined variable has DataType")
for every DI node manager - a misleading error, since the lookup had simply never
been supplied rather than the variable being absent.

Delegates to NodeStateLookupExtensions.FindByDataType rather than hand-rolling the
scan a fourth time in this file.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

DiNodeManager constructed NodeManagerBuilder without the data-type resolver, so
VariableFromDataTypeId reported BadNodeIdUnknown ("no predefined variable has DataType")
for every DI node manager - a misleading error, since the lookup had simply never
been supplied rather than the variable being absent.

Delegates to NodeStateLookupExtensions.FindByDataType rather than hand-rolling the
scan a fourth time in this file.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

Merging master added an IOperationContext parameter to the NodeManager lifecycle add operation, so these tests no longer bound their argument to the intended overload. They pass null because the registration is created by the test fixture rather than on behalf of an executing request.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

…ransfer' into marcschier/wot-09-xregistry-client

…nt' into marcschier/wot-10-wotcon-model

…into marcschier/wot-11-bindings-core

… into marcschier/wot-12-executors

…o marcschier/wot-13-registry

… marcschier/wot-15-client

…arcschier/wot-14-materialization

…n' into marcschier/wot-16-samples

## Summary
- add optional WoT Connectivity asset TD mirroring into the WoT
xRegistry
- add DI opt-in via AddWotRegistryBridge and direct
WotConnectivityServerOptions.RegistryBridge fallback
- document default-off, best-effort failure policy and usage
- add NUnit/Moq coverage for create, update, delete, disabled and
failure paths

## Validation
- dotnet build src\\Opc.Ua.WotCon.Server\\Opc.Ua.WotCon.Server.csproj -c
Release -v:m (all TFMs, 0 warnings/errors)
- dotnet test tests\\Opc.Ua.WotCon.Tests\\Opc.Ua.WotCon.Tests.csproj -c
Release -p:CustomTestTarget=net10.0 (0 failed / 983 passed)

---------

Copilot-Session: 9e6a5abf-3299-4cd1-9855-010fedbf0ad8

…ransfer' into marcschier/wot-09-xregistry-client

…nt' into marcschier/wot-10-wotcon-model

…into marcschier/wot-11-bindings-core

… into marcschier/wot-12-executors

…o marcschier/wot-13-registry

… marcschier/wot-15-client

…arcschier/wot-14-materialization

…n' into marcschier/wot-16-samples

…marcschier/wot-16-samples

…ion (#4156)

Adds the runnable WoT Connectivity samples and completes the
documentation. This is **PR 16 of a
stack** splitting #4093, and the last one.

## Samples

Three projects under `samples/WotCon/`:

* **FlatTagServer** — a plain OPC UA server exposing flat tags, used as
an aggregation source.
* **AggregationServer** — registers Thing Descriptions with the WoT
registry and materializes two
flat sources into a runtime-loaded DI/Machinery/Pumps Pump model. It
also ships a small in-memory
protocol binding, which is the worked example the binding contributor
guide walks through.
* **AggregationClient** — drives the aggregated model: commands,
`Refresh`, monitoring, and
  generation replacement.

## Documentation

* New `docs/WotBindings.md` — the bindings that ship today
(planner/executor architecture, bundled
vs separate packages, operation coverage, target mapping, lazy channels,
generation lifetime) plus
the contributor guide for adding your own, with diagnostics, tests,
packaging, TFM, trimming and
  NativeAOT guidance.
* Expanded `docs/WoTConnectivity.md` covering the registry,
dependency-closure materialization and
  runtime NodeSet projection.
* `docs/RuntimeNodeSets.md` gains the shadow-reload section and
`docs/XRegistry.md` the shared
byte-store section. Both document APIs introduced earlier in the stack;
they are collected here
  because this is the documentation PR.
* `docs/README.md` links the new pages.

## Solution registration

Registers the three samples and `Opc.Ua.WotCon.Samples.Tests` in
`UA.slnx` so CI actually builds
and runs them.

## Stack position

Sits on top of **#4154** (materialization) and additionally merges
**#4142** (registry client) and
**#4144** (protocol executors), because the samples exercise the whole
stack — `AggregationServer`
needs the OPC UA executor and the client sample needs the registry
client. Its diff therefore shows
their content until they land.

It also carries `WotRegistryProjectionLiveTests.cs`, which #4154
deliberately left out: those tests
need both the materialization runtime *and* the registry client, so this
is the first branch where
they compile.

## Validation

* All three samples build clean on every target framework.
* `Opc.Ua.WotCon.Tests`: **830 passed**, 0 failed (769 from #4154 plus
61 from the live projection
  tests).
* `Opc.Ua.WotCon.Samples.Tests`: 6 of 7 pass locally; the remaining one
fails with
`CryptographicException: The system cannot find the path specified`, a
known certificate-store
problem on this machine that was previously reproduced against a clean
baseline worktree and is
  not related to this change. CI will confirm.
* 0 warnings, 0 errors.

One fix was needed while bringing the sample across: its memory binding
called `ResolveCodec` with
the pre-`out WotPayloadDescriptor` signature. The API gained the payload
out-parameter and a
`bool` result during review of the binding PRs, so the sample now
follows the same
`if (!ResolveCodec(...)) return Unsupported(...)` pattern as the shipped
planners.

Integration PR: #4093.

…pace (#4154)

PR 14 of the stacked series splitting the large WoT Connectivity
integration PR #4093.

This PR adds the server-side materialization runtime that turns WoT
Thing Description resources from the xRegistry snapshot into OPC UA
address-space projections. The coordinator builds the dependency closure
for each resource, plans binding metadata, activates binding channels,
and publishes the resulting projection through the registry NodeManager
so refresh, retire, and reload operations remain observable and
deterministic.

Projection intentionally goes through the NodeManager lifecycle reload
API instead of mutating live nodes directly. That keeps complex type
reload, runtime NodeSet publication, shadow reload, immediate reload,
and retirement on the same lifecycle path as other dynamic server
address-space changes.

This branch has a triple dependency. It is based on #4146 (registry),
and additionally needs #4147 (lifecycle reload API) and #4128
(2-argument TryGetStructure). Both #4147 and #4128 are merged into this
branch, so this PR's diff will show their content until those
dependencies land.

Validation performed:
- dotnet build src\Opc.Ua.WotCon.Server\Opc.Ua.WotCon.Server.csproj -c
Release -f net10.0 -v:m
- dotnet build tests\Opc.Ua.WotCon.Tests\Opc.Ua.WotCon.Tests.csproj -c
Release -p:CustomTestTarget=net10.0 -v:m
- dotnet test tests\Opc.Ua.WotCon.Tests\Opc.Ua.WotCon.Tests.csproj -c
Release -p:CustomTestTarget=net10.0 --no-build
- dotnet build tests\Opc.Ua.WotCon.Tests\Opc.Ua.WotCon.Tests.csproj -c
Release -p:CustomTestTarget=net48 -v:m
- dotnet test tests\Opc.Ua.WotCon.Tests\Opc.Ua.WotCon.Tests.csproj -c
Release -p:CustomTestTarget=net48 --no-build
- dotnet build tests\Opc.Ua.Server.Tests\Opc.Ua.Server.Tests.csproj -c
Release -p:CustomTestTarget=net10.0 -v:m
- dotnet test tests\Opc.Ua.Server.Tests\Opc.Ua.Server.Tests.csproj -c
Release -p:CustomTestTarget=net10.0 --no-build (one known inherited
failure: LiveNodeManagerAddRefreshesTheClientNamespaceTable)

PR 15 of a stacked split of integration PR #4093 into independently
reviewable pieces.

This branch is stacked on #4139 (`marcschier/wot-10-wotcon-model`) and
additionally has #4128 (`marcschier/wot-01-core-types`) and #4130
(`marcschier/wot-09-xregistry-client`) merged in so this client slice
can build.

Those extra dependencies are intentional:
- Without #4130: `WotRegistryClient.cs:83` — `error CS1729:
'XRegistryClient' does not contain a constructor that takes 4
arguments`.
- Without #4128: `WotRegistryClient.cs:346,375` and
`WotRegistryResourceClient.cs:144` — `error CS1501: No overload for
method 'TryGetStructure' takes 2 arguments`.

The extra diff from #4128 and #4130 disappears once those PRs land.

This PR adds the WoT Connectivity registry client surface for browsing
and reading registry groups, resources and versions, uploading documents
through FileTransfer, invoking registry methods, and registering the
client through DI/builder helpers.

Adds the WoT Connectivity registry service and stores for Thing
Description and Thing Model documents.

This is PR 13 of the stacked split of integration PR #4093 and is
stacked on #4140 (`marcschier/wot-11-bindings-core`). The
materialization runtime that consumes this registry follows separately.

The registry has no dependency on the binding runtime or the NodeManager
lifecycle; the stacking is only because this change shares the WoT
Connectivity server project file with the preceding PRs.

Validation:
- `dotnet build src\Opc.Ua.WotCon.Server\Opc.Ua.WotCon.Server.csproj -c
Release -f net10.0 -v:m`
- `dotnet build tests\Opc.Ua.WotCon.Tests\Opc.Ua.WotCon.Tests.csproj -c
Release -p:CustomTestTarget=net10.0 -v:m`
- `dotnet test tests\Opc.Ua.WotCon.Tests\Opc.Ua.WotCon.Tests.csproj -c
Release -p:CustomTestTarget=net10.0 --no-build -v:q`
- `dotnet build src\Opc.Ua.WotCon.Server\Opc.Ua.WotCon.Server.csproj -c
Release -v:m`

## Summary
- Adds the concrete WoT binding transport executors for HTTP, Modbus
TCP, OPC UA and MQTT.
- Includes executor/channel tests and in-process HTTP, Modbus, MQTT and
OPC UA harness coverage.
- Leaves CoAP, BACnet, PROFINET and LoRaWAN planner-only because this
stack split intentionally lands validation/planning before executable
transports.

## Stack context
This is PR 12 of the stacked split of integration PR #4093. It is
stacked on #4140, where the protocol-agnostic planner layer landed
separately, so this PR is limited to the concrete transport
implementations.

## Validation
- `dotnet build
tests\Opc.Ua.WotCon.Bindings.Tests\Opc.Ua.WotCon.Bindings.Tests.csproj
-c Release -p:CustomTestTarget=net10.0 -v:m`
- `dotnet test
tests\Opc.Ua.WotCon.Bindings.Tests\Opc.Ua.WotCon.Bindings.Tests.csproj
-c Release -p:CustomTestTarget=net10.0 --no-build` (512 passed)
- `dotnet build src\Opc.Ua.WotCon.Bindings\Opc.Ua.WotCon.Bindings.csproj
-c Release -v:m`
- `dotnet build
src\Opc.Ua.WotCon.Bindings.Mqtt\Opc.Ua.WotCon.Bindings.Mqtt.csproj -c
Release -v:m`

## Summary

PR 11 of the stacked split for integration PR #4093. This adds the
protocol-agnostic core of `Opc.Ua.WotCon.Bindings`: binder, planner,
executor and channel-factory contracts; payload codec and credential
provider seams; the binding plan model; polling subscriptions for forms
without native observation; and DI/builder registration helpers.

This PR is stacked on #4139, which itself depends on #4132 and #4134.

## Scope

The included planners validate forms and produce binding plans without
transport I/O:

- HTTP planner and validation only; the concrete HTTP executor follows
in the next PR.
- MQTT planner and validation only; the separate MQTT executor package
follows in the next PR.
- Modbus TCP planner and shared Modbus type/limit definitions only; the
Modbus executor and TCP client follow in the next PR.
- OPC UA planner and validation only; the concrete OPC UA executor
follows in the next PR.
- CoAP, BACnet, PROFINET and LoRaWAN are planner/validation-only in this
split.

Keeping concrete transport executors out of this PR makes the
abstractions and planning layer reviewable without a network stack.

## Validation

- `dotnet build
tests\Opc.Ua.WotCon.Bindings.Tests\Opc.Ua.WotCon.Bindings.Tests.csproj
-c Release -p:CustomTestTarget=net10.0 -v:m`
- `dotnet test
tests\Opc.Ua.WotCon.Bindings.Tests\Opc.Ua.WotCon.Bindings.Tests.csproj
-c Release -p:CustomTestTarget=net10.0 --no-build`
- `dotnet build src\Opc.Ua.WotCon.Bindings\Opc.Ua.WotCon.Bindings.csproj
-c Release -v:m`

This is PR 10 of the stacked split of integration PR #4093 into
independently reviewable pieces.

Stack/dependency shape:

- This branch is stacked on #4134 (`marcschier/wot-04-generator-wot`).
- It also requires #4132 (`marcschier/wot-02-sourcegen`), which is
merged into this branch so the model can build.

The #4132 dependency is functional, not cosmetic. Without #4132,
building the WoT Connectivity model on #4134 alone fails with duplicate
generated declarations, for example:

```text
CS0102: The type 'Methods' already contains a definition for 'CreateAssetMethodType'
```

That occurs because the combined WoT-Con NodeSet ships the 1.02
`CreateAssetMethodType` node explicitly; without #4132's
NodeSet-to-ModelDesign fix, the generator synthesizes a second
declaration with the same name.

Once #4132 and #4134 land, the extra diff from those dependencies
disappears and this PR reduces to the three WoT Connectivity model
files:

- `src\Opc.Ua.WotCon\Design\Opc.Ua.WotCon.NodeSet2.xml`
- `src\Opc.Ua.WotCon\Design\Opc.Ua.WotCon.NodeSet2.csv`
- `src\Opc.Ua.WotCon\Opc.Ua.WotCon.csproj`

The generated C# is produced from the pinned NodeSet2 at build time. I
verified it builds from clean after deleting the WotCon `bin`/`obj`, the
source-generation tool `bin`/`obj` directories, and shutting down dotnet
build servers.